Making DSOs Self-Contained

Making DSOs Self-Contained

When building a DSO, be sure to include any archives required by the DSO on the link line so that the DSO is self-contained (that is, it has no unresolved symbols). If the DSO depends on libraries not explicitly named on the link line, subsequent changes to any of those libraries may result in name space collisions or other incompatibilities that can prevent any applications that use the DSO from doing a QuickStart. Such incompatibilities can also lead to unpredictable results over time as the libraries change asynchronously. Suppose you want to make the archive libmine.a into a DSO, and libmine.a depends on routines in another archive, libutil.a. In this case, include libutil.a on the link line:

ld -shared -all -no_unresolved libmine.a -o libmine.so -none libutil.a

This causes the modules in libutil.a that are referenced in libmine.a to be included in the DSO, but these modules won't be exported. (For more information about exported symbols, see "Controlling Symbols to Be Exported or Loaded.") The -no_unresolved option causes a list of unresolved symbols to be created; generally, this list should be empty to enable using QuickStart.

Similarly, if a DSO relies on another DSO, be sure to include that DSO on the link line. For example:

ld -shared -all -no_unresolved libbtree.a -o libtree.so -lyours

This example places libyours.so in the liblist of the new DSO, libtree.so. This ensures that libyours.so is loaded whenever an executable that uses libtree.so is launched. Again, symbols from libyours.so won't be exported for use by other libraries. (You can use the -exports flag to reverse this exporting behavior; the -hides flag specifies the default exporting behavior.)